1. Field of the Invention
This invention relates to event notification and distribution between computer systems, and more specifically to global event notification in a distributed computing environment, such as a computer network.
2. Prior State of the Art
Distributed computing environments are typically made up of several systems and resources. For example, Local Area Networks (LAN), Wide Area Networks (WAN), and other types of computer networks typically involve many computer systems connected together via physical communication links. Many networks comprise two or more interconnected servers. User or client systems then attach to one or more of these servers. In addition, servers may have attached peripherals which are available to users of the network. For example, many office networks have various devices which are available to all users of the network, such as printers, fax machines, modems, and the like.
In order to share information and resources among the various systems in a computer network, systems must be able to discover the status of other systems or devices in the network. For example, when a file is to be printed by a network printer, the file must be transferred to the server which is responsible for printing; typically the server physically attached to the printer. Before such a transfer takes place, it may be desirable to discover or ascertain the status of the network printer. For example, if the network printer is off-line or otherwise unavailable, there would be little benefit to transferring a file to the printer for printing. As another example, after a file is finished printing, it may also be desirable to inform the user that the print job is completed. Thus, in a distributed computing environment there is a need for systems to be able to discover when certain events happen on other systems. Although such a mechanism was once accomplished by polling (requesting the status of other systems), today's modem architectures utilize an event notification procedure.
In an event notification procedure, when an event occurs that should be known by other systems, the system where the event occurs sends a message to the other systems to notify them of the event. This notification can be called "event notification" and is typically accompanied by a message packet containing data associated with the event. In a computer network, systems or processes which produce events can be referred to as "event producers" and systems or processes which should be notified of the event can be called "event consumers."
When an event consumer receives notification that a certain event happened on an event producer, the event consumer can take appropriate action. In the case of one example given above, if the network was set up to notify a user when a file had finished printing, after the file had been printed, the server responsible for printing the file would generate an event notification that printing had finished. This event notification would then be passed to the user to notify the user that printing had concluded.
By its very nature, event notification is a local phenomenon. In other words, an event producer notifies event consumers of events which happen locally to the event producer. Event consumers which desire to receive notification of certain events "register" with the event producing system. When an event occurs, notification is sent to all registered event consumers.
Although such an event notification system provides many benefits and advantages, it also has many shortcomings and drawbacks. For example, event notification processes arc typically single-thread execution processes. This means that when an event occurs, a process begins running on the event producing system which contacts each registered event consumer and notifies them of the event. The registered event consumers are contacted, one after the other, until all event consumers have been notified. This tends to create a situation where the event producing system is prevented from performing other tasks until all event consumers have been notified.
Because a connection must be established between the event producer and the event consumers, a situation can arise where a large amount of message traffic is created on the computer network. Thus, it is important to minimize the time it takes to contact each event consumer and minimize the amount of message traffic generated on the network.
Another problem with current event notification systems is the inability to generate global event notification. As previously discussed, by its very nature, event notification is a localized phenomenon. In other words, an event producer notifies all event consumers that are registered for a particular event. Thus, an event consumer that desired notification of all events of a particular type must register for the event at each server. For example, consider a situation where a network comprises three servers, server A, server B, and server C. Server A and server B each have a network printer attached thereto. A user on server C desires to know when any file he prints from either printer is completed. In such a situation, the user must register for a print job finished type event at both server A and server B. Failure to register for events on both servers will create the possibility of missing a desired event. In large networks with many events of interest, registering for events on each and every server can be a time consuming and cumbersome process. It would, therefore, be an advancement in the art to provide global event notification across an entire network without the need to register at each server.
Another problem with prior art event notification systems is that events tend to be broadcast events. This results in sending a large number of event notifications that are of little or no interest to the event consumer. As previously described, an event producer will contact all registered event consumers and notify them of the event. Many events, however, are of little or no interest to many registered users. For example, suppose a system had a create object event. Now suppose an event consumer wished to be notified when a directory object on a certain system disk was created. Under prior art event notification systems, this event consumer would register for the create object event. This would have the effect of not only notifying the event consumer of a directory object created on the particular disk of interest, but also of every other object created on any disk. Thus, this event consumer would receive many notifications that were of no interest. It would, therefore, be advantageous to be able to register only for events meeting certain criteria.
A still further problem with prior art notification systems can be identified by considering the following example. Many network environments contain a large database of shared data. Such a database can contain, for example, the log-in names and passwords of all users who are authorized to connect to the network. A wide array of other information may also be associated with such user account information. Such information can include a user's full name, an address, billing numbers, department, or any other type of information. In order to allow all servers on the network to know which resources are available on the network, such a database also often contains network device information such as a listing of the computer servers in the network and attached peripherals such as mass storage devices, printers, modems, and the like.
Experience has shown that as networks grow to hundreds, thousands, or tens of thousands of systems and users, the size of such a database becomes larger than any one system can store and maintain. In such a situation, the database is often broken up and scattered among various servers in the network. Thus, server A may contain part 1 of the database, server B may contain part 2 of the database, and server C may contain part 3 of the database.
Sometimes, in order to provide redundancy and prevent loss of the database, portions of the database are replicated on different systems. For example, server A may contain parts 1 and 3 of the database. Server B may contain parts 2 and 1 of the database, and server C may contain parts 3 and 2 of the database. In such a configuration, if any single system is lost, the remaining systems still have an entire copy of the database.
While breaking the database up among systems helps to provide robustness and eliminates the problem of having a single database on one system, it also creates several problems for event notification systems. Because event notification is a local phenomenon, if an event consumer wishes to be notified when a user is added to the system, the event consumer must be registered with enough servers to ensure connections to all parts of the database. This is because if the event consumer only registers with Server A, then in the example given above, the event consumer will only be notified if parts 1 and 3 are changed. If, in this example, part 2 of the database was changed, then an event would not be generated by Server A and the event consumer would not be notified. Prior art systems therefore require registration with a plurality of servers in order to effect notification if any portion of the database is changed. This results in multiple or redundant notifications for a single event. This can be illustrated by the following example.
Suppose part 1 of the database was changed. Further suppose that an event consumer who wished to be notified of changes in the database registered with Server A (containing parts 1 and 3 of the database) and Server B (containing parts 2 and 1 of the database). When Server A modifies part 1 of the database, Server A will send notification of this event to the event consumer registered for the database modification event. In order to synchronize part 1 of the database on server A with part 1 of the database on server B, server A will send a message to server B so that server B can update its copy of part 1 of the database. When server B updates its part 1 of the database, however, it will realize that an event consumer has registered for the database modification event and send notification to the event consumer of the modification of part 1 of the database located on server B. Thus, the event consumer receives two notifications for a single modification, one from server A and one from server B. It would, therefore, be advantageous to have an event notification system which could eliminate duplicate events so that only a single notification is sent to registered event consumers.
Finally, prior art event notification systems lack certain functionality that is highly desirable. For example, current event notification systems do not provide a mechanism for an event producer who is also a user to trigger a customized event. Thus, it would be desirable to allow event producers, including event producers that are also users, to trigger custom events that can be globalized to all event consumers in the network.
In addition to the ability to trigger custom events, it would also be desirable to provide events that are directed. As previously described, prior art event notification systems notify all registered users of a particular event. Thus, there is currently no mechanism to allow an event to be directed to a specific event consumer to the exclusion of all other event consumers, even though the other event consumers have registered for a particular event. It would be an advancement in the art to provide this capability.